New Fine-Grained Bundle Permissions

We need a more fine-grained security model surrounding bundle deployments:

• Creation and Deletion of Bundles

  • Global Permission CREATE_BUNDLES - a user can create his own bundle or bundle version

  • Global Permission DELETE_BUNDLES - a user can delete his own bundle or bundle version

  • Global Permission DELETE_ALL_BUNDLES - a user can delete any bundle or bundle version, including those not his own

  • If a user has DELETE_BUNDLES, the user should automatically be given CREATE_BUNDLES (it doesn't make sense to be able to delete your own bundles unless you can create them first). Note the reverse is not necessarily true - it may be you don't want users deleting bundles, even if they created them.

  • When we say "create" bundle or "delete" bundle, it should (probably?) also include bundle versions as well (CREATE_BUNDLES means I can create a new version 2.0 for bundle A (or delete it), but only if bundle A is my own bundle. I can't create a new version 2.0 (or delete it) for bundle B if bundle B is not owned by me.) These restrictions are lifted if I have DELETE_ALL_BUNDLES (that is, I can delete anything). I don't think it makes sense for user A to be able to create bundle versions under a bundle created by user B. I'm not sure. Does it make sense to introduce CREATE_ALL_BUNDLES that allows me to add a bundle version under another user's bundle? If we allow that, I think a major change will need to be added to the bundle storage code.

• Viewing Existing Bundles

  • Users must not be able to view bundles or bundle versions unless they are bundles/bundle versions they themselves created.

  • If a user has CREATE_BUNDLES (or DELETE; but if you have DELETE, you have CREATE), it implies they can view their own bundles

  • Global Permission VIEW_ALL_BUNDLES - a user can view all bundles, including those not his own

  • If a user has DELETE_ALL_BUNDLES, the user should automatically be given VIEW_ALL_BUNDLES

• Deploying Bundles

  • Resource Permission DEPLOY_BUNDLE - if the user has this permission, he can deploy his own bundles to resource groups assigned to his roles.

  • This could include purging and rolling back bundles as well. Should we make this even more fine grained? Say, add UNDEPLOY_BUNDLE to allow for undeploy/rolling back/purge?

What to do with existing MANAGE_BUNDLES permission

Today, there is a coarse-grained, uber-permission MANAGE_BUNDLES. If you have this global permission, you can create, delete, deploy and pretty much do anything in the bundle subsystem. We could leave this in the code for backward compatibility. MANAGE_BUNDLE could be analogous to MANAGE_INVENTORY (where you have all access to everything in inventory). If a user has MANAGE_BUNDLE, it would imply the user has all of the new proposed permissions (CREATE_ALL_BUNDLE, DEPLOY_BUNDLE, etc.)

A Potential Enhancement To the Security Subsystem

In the above, notice the DEPLOY_BUNDLE allows you to deploy only your own bundles to resource groups assigned to the role. I think one requirement we have is for a user to be allowed to deploy bundles that might have been created by someone else. How can we allow for this?

First, you need to understand today's RHQ security model, which is this:

RESOURCE GROUPS ---> ROLES <--- USERS
                       |
                  permissions

So you define a role (which has certain permissions enabled, like these newly proposed ones CREATE_BUNDLES, DEPLOY_BUNDLES, etc). If a permission is a GLOBAL permission, it does not involve resource groups, it takes affect globally. If a permission is a RESOURCE permission (like the above proposed DEPLOY_BUNDLE), it is restricted in that it applies only for resources found in resource groups assigned to the role that provides the permission.

What this means is that DEPLOY_BUNDLE can be restricted to only allow the user to deploy his own bundles to resource groups that that user has access to.

What this does not mean is the user can deploy any bundle (not his own) to his allowed resource groups.

If we want to allow for a user to deploy a bundle (not his own) to an allowed resource group, not only does the resource group need to be assigned to the role, but so does the bundle. Today, we do not have this. We would have to add something like a new relationship between role and bundle (I'll assume if you can deploy a bundle, you can deploy any bundle version associated with that bundle) - so the new domain model would be:

                    BUNDLES
                       |
                       v
RESOURCE GROUPS ---> ROLES <--- USERS
                       |
                  permissions

If we have that new bundle relationship to roles, then an admin user can create a new role with permission DEPLOY_BUNDLE, assign resource groups to that role, assign bundles to that role, then give that role to any user. That user would then be able to deploy those bundles (question: and only those bundles? What about his own?) but only to those resource groups assigned to that role.

Proposed New Permissions

As per the above discussion, these are the proposed changes to the permissions: